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DETAILED ACTION 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Applicant's submission filed on 1 1/01/2006 has been entered. 

Response to Amendment 
1. This action is responsive to an Amendment filed 1 1/01/2006. Claims 17-21, 23, 45-47 
are pending. Claims 17, 20, 45, 46, 47 are amended. Claims 1-16, 22, 24-44 are canceled. The 
examiner hereby withdraws the objections to claims 46 and 47 in light of the amendment. 

Response to Arguments 

1 . Applicant's arguments regarding claims 17, 20, and 45, filed 1 1/01/2006, have been fully 
considered, but they are not persuasive. 

Regarding claims 17, 20, and 45, the applicant argues that the combination of Williams 
and Richardson does not disclose or suggest an analysis module that compares the original 
display elements (graphical primitives) with a set of predefined display elements (graphical 
primitives) and selects modified display elements which are closest to the original display 
elements to simplify compression in accordance with identified transmission bandwidth 
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limitations. The examiner respectfully disagrees. As mentioned in the Office Action mailed 
6/01/2006, Richardson discloses a technique for updating a framebuffer. The endpoint where 
changes to the framebuffer originate is known as the VNC server. Changing from one 
framebuffer state to another is referred to as an update. These updates are created by and sent 
from the server to the client. The pixel data of the update is divided up into a series of 
rectangles. Each of these rectangles may be encoded according to a different scheme, dependent 
on the particular screen content being transmitted and the available network bandwidth. In the 
example of copy-rectangle encoding, the server identifies the x, y coordinate position of the 
previous framebuffer state from which the client can copy a rectangle of pixel data. Thus, the 
encoding on the wire is simply an x, y coordinate. This is useful, for example, when a user 
moves a window across a screen. Since a previous framebuffer state contains graphical data (a 
window prior to be moved, for example), which may be re-used as graphical data (a window 
after being moved, for example) in the new framebuffer update, the examiner maintains that 
Richardson meets the limitation of comparing "the original display elements (graphical 
primitives) with a set of predefined display elements (graphical primitives)," as currently 
claimed. Furthermore, the examiner interprets a screen or rectangle of pixel data to be a 
graphical primitive, as claimed. Since the graphical data to be re-used in the old framebuffer 
may be altered (different x-y position, for example) from the graphical data that is needed in the 
framebuffer update, the examiner maintains that Richardson meets the limitation of selecting 
"modified display elements which are closest to the original display elements to simplify 
compression in accordance with identified transmission bandwidth limitations," as currently 
claimed. This copy-rectangle encoding may comprise only one of the rectangles in the set of 
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rectangles comprising the update. All screen changes since the last request (described within 
encoded rectangles) are coalesced into a single update. The update is then sent from the server to 
the client. Thus, in response to observed screen changes between a previous framebuffer state 
and a current state, the server creates a set of variously encoded rectangles (the set describing 
changes between the states) for effectively transmitting an update based on the particular screen 
content of the update. 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

2. Claims 17-21, 23, 45-47 are rejected under 35 U.S.C, 103(a) as being unpatentable over 
Williams, Jr. (US 6,202,21 1) in view of Richardson et al. 

Referring to claims 17, 20, and 45, the claimed "remote computing server system that 
includes a server that provides remote client access to one or more programs that are run at the 
server, remotely from one or more client systems, and wherein the server converts display 
commands generated from the one or more programs into compressed video streams" is met as 
follows: 

• The claimed "server, executing a plurality of programs, each of which generates a 
set of display commands which represent original display elements of a user 
interface for each of said plurality of programs" is met by Williams, wherein he 
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teaches a server, which maintains muhiple active desktops and applications for 
display at remotely located STB/TV combinations [coL 3, lines 31-46]. 

• The claimed "identifying limitations of the client including a compression 
required by the client, display characteristics of the remote client device, or both" 
is not expressly disclosed by Williams; however, the Richardson reference 
teaches using different encoding techniques dependent on the capabilities of the 
client and the connection between the server and the client. The examiner further 
notes that the client can request to not be sent data encoded in copy-rectangle 
encoding, because the client cannot easily read back from its framebuffer. It 
would have been obvious to one of ordinary skill in the art at the time that the 
invention was made to modify Williams to include using different encoding 
techniques dependent on the capabilities of the client, such as that taught by 
Richardson in order to allow for more efficient bandwidth usage. 

• The claimed "analysis module for comparing the original display elements with a 
set of predefined display elements stored at the server, wherein responsive to 
transmission bandwidth limitations that are identified by the server, the analysis 
module selects corresponding modified display elements from the set of 
predefined display elements that are most similar to one or more of the original 
display elements, the set of predefined elements compiled to simplify 
compression in accordance with said transmission bandwidth limitations, wherein 
the display elements comprise graphical primitives " is not expressly disclosed by 
Williams; however, the Richardson reference teaches different encoding 
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techniques, which are used for various video encoding schemes for rendering 
desktops and other applications generated at a server on a display of a client. 
Richardson teaches that a connection speed (connection capability) is analyzed 
and an encoding scheme is chosen based on the capability of the connection from 
server to client. Changes to the firamebuffer originate at the VNC server. When 
an update is required, the update affects only a small area of the framebuffer. 
Each rectangle is encoded using a different scheme. The server chooses the 
encoding most appropriate for the particular screen content being transmitted and 
the available network bandwidth. All screen changes since the last request are 
coalesced into a single update. Richardson further teaches copy-rectangle 
encoding, which copies portions of the video signal instead of using raw data 
signal, in order to conserve bandwidth. If the client already has the same pixel 
data elsewhere in its framebuffer, the encoding on the wire is simply an x, y 
coordinate, which gives the client a position in the framebuffer from which it can 
copy the rectangle of pixel data. Thus, if a user were to move a window across a 
screen and an update were requested, the server would choose copy-rectangle 
encoding for the particular rectangle. It would have been obvious to one of 
ordinary skill in the art at the time that the invention was made to modify 
Williams to include encoding different rectangles according to different schemes 
in response to the particular screen content being transmitted and the available 
network bandwidth, such as that taught by Richardson in order to save bandwidth. 
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Note: The language "to simplify compression, utilize a pre-compressed display 
element, or both" is an advantage of the limitation. It is not a further limitation of 
the claim. 

• The claimed "video compressor which receives the modified display elements 
selected above and generates there from a compressed video stream for each one 
of the plurality of programs" is not specifically disclosed in Williams, though the 
fact that the video information is multiplexed for delivery [col. 7, lines 13-19] 
would lead one to incorporate the compression teachings of the Richardson 
document. Richardson discloses Virtual Network Computing, which transmits 
compressed video images to a client. The compression is discussed with regards 
to the MPEG standard [page 35, A Single Graphics Primitive] for compressing 
and encoding before transmission. It would have been obvious to one of ordinary 
skill in the art at the time of the invention to utilize a compressor to compress the 
video streams before transmission to the client, in order to allow for more 
efficient bandwidth usage, while, at the same time, complying with compression 
standards for transmission. 

• The claimed "transmitter for the transmission of the plurality of compressed video 
streams to one or more remote locations" is not expressly disclosed in Williams, 
though the fact that the video information is multiplexed for delivery [col. 7, lines 
13-19] would lead one to incorporate the compression teachings of the 
Richardson document. Richardson discloses Virtual Network Computing, which 
transmits compressed video images to a client. The compression is discussed 
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with regards to the MPEG standard [page 35, A Single Graphics Primitive] for 
compressing and encoding before transmission. It would have been obvious to 
one of ordinary skill in the art at the time of the invention to transmit compressed 
video streams to the client, in order to allow for more efficient bandwidth usage, 
while, at the same time, complying with compression standards for transmission. 
Referring to claims 18, 21, and 46, the claimed "set of display elements stored include 
one or more backgrounds, icons, buttons, menus, or fonts" is not specifically disclosed by 
Williams; however, Richardson discloses an encoding scheme that takes advantage of the fact 
that a typical desktop has large areas of solid color and text. The encoding scheme describes 
rectangles consisting of one majority (background) color and "sub-rectangles" of different 
colors. Richardson further discloses a pixel-data caching scheme that could efficiently encode 
multiple occurrences of the same text character by referring to the first occurrence. It would 
have been obvious to one of ordinary skill in the art at the time that the invention was made to 
modify Williams to include an encoding scheme that takes advantage of the fact that a desktop 
has large areas of solid color and text, such as that taught by Richardson in order to allow for 
more efficient bandwidth usage. 

Note: The USPTO considers the applicant's ''one or more" language to be anticipated by any 
reference containing any of the subsequent corresponding elements. 

Referring to claims 19, 23, and 47, the claimed "the set of predefined display elements 
stored differ from the original display elements by one or more color, spatial frequency 
spectrum, size, contrast, or type" is not specifically disclosed by Williams; however Richardson 
discloses describing rectangles consisting of a majority (background) color and "sub-rectangles" 
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of different colors as an effective encoding scheme for taking advantage of the fact that a typical 
desktop has large areas of solid color. It would have been obvious to one of ordinary skill in the 
art at the time that the invention was made to modify Williams to include an encoding scheme 
that takes advantage of the fact that a desktop has large areas of solid color and text, such as that 
taught by Richardson in order to allow for more efficient bandwidth usage. 
Note: The USPTO considers the applicant's "one or more" language to be anticipated by any 
reference containing any of the subsequent corresponding elements. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Michael Van Handel whose telephone number is 571-272-5968. 
The examiner can normally be reached on 8:00am-5:30pm Mon.-Fri.. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Chris Grant can be reached on 571-272-7294. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 



Conclusion 




CHRIS KELLEY 
SUPERVISORY PATENT EXAMINER 
TECHNOLOGY CENTER 2600 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
appHcations is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you v^ould 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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TRISTAN Richardson, quentin STAFFORO-FRAsot, 

KENNETH R. WOOD, AND ANDY HOPPER* 

The Olivetti & Or ado Research Laboratoty 






TIP so-called network computer (NC) alms to give users access 
to centralized resources from simple, inexpensive devices. 
These devices act as clients to more powerful server machines 
that are connected to the network and provide applications, data, and 
storage for a user s preferences and personal customlzations. We have 
taken this Idea a stage further. In the virtual network computing 
(VNC) system, server machines supply not only applications and data 
but also an entire desktop environment that can be accessed from any 
Internet-connected machine using a simple software NC. Whenever 
and wherever a VNC desktop Is accessed, Its state and configuration 
(right down to the position of the cur^r) are exactly the same as when 
it was last accessed. 

In contrast to many recent Internet applications, which have 
focused on giving users access to resources located anywhere in the, 
world from their home computing environments. VNC provides 
access to home computing environments from anywhere In the 
world. Members of the Olivetti & Oracle Research Laboratory 
(ORL) use VNC to access their personal Unix and PC desktops from 
any office in our Cambridge building and from around the world on 
whatever computing Infrastructure happens to be available — Includ- 
ing, for example, public Web*browsing terminals in airports. VNC 
thus provides mobile computing without requiring the user to carry 
any device whatsoever. In addition, VNC allows a single desktop to 
be accessed from several places simultaneously, thus supporting appli* 

'Andy Hopper Is atso sfflOaied wtan Cambridge Unlvenlty Engineering Oeparvnert. 
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cation sharing in the style of computer-supported cooper- 
aUve work (CSCW). 

The technology underlying VNC is a simple remote- 
display protocol. It Is the simplicity of this protocol that 
makes VNC so powerful. Unlike other remote display pro- 
tocols such as the X Window System and Chrix's ICA. the VNC 
protocol is totally Independent of operating system, win- 
dowing system, and applications (see the sidebar. "Thin 
Clients"). The VNC system is freely available for download 
from the ORLWeb site at http://www.orlxo.uk/vnc/. 

We begin this article by summarizing the evolution of 
VNC from our work on thln<cllent archluctures. We then 
describe the structure of the VNC protocol and conclude by 
discussing the ways we use VNC technology now and how 
it may evolve further as new clients and servera are developed 



THE ORIGINS OF VNC 

The X Window System allows applications to display a user 
Interface on a remote machine. ORL extended this func- 
tionality in our Teleporting System by allowing the user Inter- 
face of a running X application to be dynamically redirect- 
ed to a different display.'-^ Teleporting has been In daily use 
at ORL for several years now. There are. however, several 
problems with X that restrict its use in the wide area and. In 
turn, restrict systems based on it, such as Teleporting: 

■ X requires the display machine to run an X server pro- 
gram. This heavyweight piece of software requires sub- 
stantial resources, which machines such as NCs and per- 
sonal digital assistants ^DAs) caruiot be expected to run. 

■ The X security model makes it inherently dangerous to 
allow a remote machine to use your display. According- 
ly, most system administrators stop X traffic from pass- 
ing in or out of their sites. 

■ Application startup Is extremely slow on high-latency links 
due to the number of round-trips performed by a typical 
application (though there are special proxies that alleviate 
this problem, such as Low Bandwidth X ILBX]^). 

In addition to these technical problems, there Is also the 
nontechnical problem that X is not Windows, and the world 
is becoming increasingly Mlcrosoft-dominaud. 

Videotile: An Ultra-Thin Client 

In 1 994. ORL built the Videotile as an experiment in ultra- 
thin<llent technology. The Videotile is a display device with 
an LCD screen, a pen, and an ATM network connection. It 
was designed to display good-quality video, but we also 
wanted to use It to interact with applications. As a first 
experiment toward this end, we treated a remote computer 
screen as a video source and simply shipped the user inter- 
face as raw video onto the tile. This worked surprisingly well, 
but used a significant amount of bandwidth. 

By adding a little more intelligence at the application 
side, we were able still to treat the user interface as video, but 
to send only those parts of the screen that changed. This idea 
developed into the VNC protocol. 

Java: Access Through a Browser 

When Sun Microsystems released the alpha version of the Java 
language and the Hotjava browser In 1995. we realized we 
could implement the Videotile mechariism In Java to access 
appUcatlons through a Web browser. The thln-dient paradigm 
made the adaptation to Java very straightforward. We wrote 
the original Java client In a day and the resulting class file was 
a mere 6 kilobytes in size. This eventually became the VNC 
applet described in more detail elsewhere.^ Any Java-capable 
browser could now provide access to a users desktop, givlrtg 
the mobility of the Teleporting system, but on a global scale. 
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THE VNC PROTOCOL 

The technology underlying the VNC system is a simple pro- 
tocol for remote access to graphical user interfaces. It works 
at the framebufTer level and therefore applies to all operating 
systems, windowing systems, and applications — indeed to any 
device with some form of communications linlc The proto- 
col will operate over any reliable transport such asTCP/IR 

The endpoint with which the user Interacts (that is. the 
display and/or Input devices) is called the VNC client or 
viewer. The endpoint where changes to the framebuifer orig- 
inate (that is, the windowing system and applications] is 
known as the VNC server (see Figure 1). 

VNC Is truly a "thin-dient' system. Its design makes veiy 
few requirements of the client, and therefore simplifies the 
task of creating clients to run on a wide range of lurdware. 

A Single Graphics Primitive 

The display side of the protocol Is based on a single graphics 
primitive: 

Put a rectangle of pixel data at a given x, y position. 

At first glance this might seem an inefficient way to draw 
some user interface components. However, allowing various 
encoding schemes for the pUel data gives a large degree of 
flexibility in trading off parameters such as network band- 
width, client drawing speed, and server processing speed. 

The lowest common denominator is the so-called raw 
encoding, where the pbcel data for a rectangle is simply sent In 
left-to-right scanline order. All VNC clients and servers must 
support this encoding. However, the encodings actually used 
on a given connection can be negotiated according to the 
capabilities of the server and client and the connection 
between them. 

For example, copy-rectangie encoding\i very simple aiKl effi- 
cient, and can be used when the client already has the same 
pbcel data elsewhere In its framebufTer. Tiie encoding on the 
wire is simply an x, /coordinate. This gives a position in the 
framebufTer from which the client can copy the rectangle of 
pbcel data. This encoding Is typically used when the user moves 
a window across the screen or scrolls a window s contents. 

Most clients will support copy- rectangle encoding, since 
it Is generally easy to implement* saves bandwidth, and is 
likely to be faster tiian sending raw data again. However, In 
a case where a client cannot easily read back from its frame- 
bufTer, the client could specify that it should not be sent data 
encoded this way. 

A typical workstation desktop has large areas of solid 
color and text. One of our most effective encodings takes 
advantage of this phenomenon by describing rectangles con- 
sisting of one majority (bacltground) color and *'sub-rectan- 
gles' of different colors. There are numerous other possible 
schemes. We could use a JPEG encoding for efficient trans- 



VNC server VNC viewer (diem) 




Figure 1. VNC architecture. 

mission of still images or an MPEG encoding for moving 
Images. A pixel-data caching scheme could efftciendy encode 
multiple occurrences of the same text character by referring 
to the first occurrence. 

Adaptive Update 

A set of rectangles of pUel data makes a riamebuffer update 
(or simply, updat^- An update represents a change from one 
valid framebuffer state to another. In this sense, an update 
is similar to a frame of video. It differs, however, in that it 
usually affects only a small area of the framebufTer. Each rec- 
tangle may be encoded using a different scheme. The server 
can therefore choose the encoding most appropriate for the 
particular screen content being transmitted and the avail- 
able network bandwidth. 

The update protocol is demand-driven by the client That 
is, an update is only sent by the server in response to an explic- 
it request from the client. All screen changes since the client's 
last request are coalesced into a single update. This gives the 
protocol an adaptive quality: the slower die client and the net- 
work, the lower the rate of updates. On a fast network, for 
example, as the user drags a window across the screen it will 
move smoothly, being drawn at all the Intermediate positions. 
On a slower link — for example, over a modem — the client 
will request updates less frequenUy. and the window will 
appear at fewer of these positions. TlUs means that the display 
will reach its final state as quicldy as the network bandwidth 
will allow, thus maximizing the speed of interaction. 

Input 

The input side of the VNC protocol is based on a sundard 
workstation model of a keyboard and multlbutton pointing 
device. The client sends input events to the server whenev- 
er the user presses a key or pointer button, or moves the 
polndng device. Input events can also be synthesized from 
other nonstandard I/O devices. On the Video tile, for exam- 
ple, a pen-based handwriting recognition engine generates 
keyboard events. 

Connection Setup and Shutdown 

To establish a client-server connecdon, the server first requests 
authentlcadon from the client, using a challenge-response 
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Figure 2. A variety of desktops being accessed from different viewers: (a) a Unix desktop from 
a Windows viewer, (b) a Windows 95 desktop from an X viewer, (c) a Unix desktop from a 
Java applet wlttiin Internet Explorer, and (d) a Windows desktop using Netscape on Unix. 



scheme; the client typically requires the user to enter a pass- 
word at this point. The server and client then exchange mes- 
sages to negotiate desktop size, pixel format, and encoding 
schemes. The client requests an update for the entire screen, 
and the session begins. Because of the stateless nature of the 
client, either side can close the connection at any time with- 
out adverse consequences. 

VNC Viewers 

In day-to-day use, we prefer the more descriptive term 
viewer to the rather overloaded word client. Writing a VNC 
viewer is a simple task, as indeed It should be for any thin- 
client system. It requires only a reliable transport (usually 
TCP/IP), and a way of displaying pixels (either writing 
directly to the framebuffer or going through a windowing 
system). 

We have written viewers for all the networked display 
devices available at ORL. These include the Videotile (the 
original VNC viewer), an X-based viewer (which runs on 
Solaris, Linux, and Digital Unix workstations), a Win32 
viewer that runs on Windows NT and 95, and a Java applet 
that runs on any Java -capable browser (including Suns 
JavaStatlon). Memben of our tab use these viewers on a dally 
basis to access their personal computing environments. 



The images in Figure 2 
show a variety of X and Win- 
dows desktops being accessed 
from both Java and native X 
and Windows viewers. 

VNC Servers 

Writing a VNC server is 
slightly harder than writing 
a viewer. Because the proto- 
col is designed to make the 
client as simple as possible, 
it is usually up to the server 
to perform any necessary 
translations (for example, 
the server must provide 
pbcel dau in the format the 
client wants). We have writ- 
ten servers for our two main 
platforms. X (that is, Unix) 
and Windows NT/95. 

The X-based server was 
the tint one we developed. A 
single Unix machine can run 
a number of VNC servers 
for different users, each rep- 
resenting a distinct VNC 
desktop. Each desktop is like 
a virtual X display, with a 
root window on which several X applications can appear. 

The Windows VNC server was a little more difllcult to 
create. Windows has fewer places to insert hooks into the sys- 
tem to monitor display updates, and the model of multiuser 
operation is less clearly defined. Our current server simply 
mirrors the real display to a remote client, which means that 
only a single VNC desktop is available from any one PC. 

The X-based server, the X viewer, the Win32 server, and 
Win32 viewer can all fit on a single floppy disk. 

We have also created "thin" servers which produce dis- 
plays other than desktops, using a simple toolkit. A "VNC 
CD player," for exannple. generates a CD player user Inter- 
face using VNC directly without any reference to a win- 
dowing system or framebuffer (see figure 3 on the following 
page). Such servers can run on very simple hardware, and 
can be accessed from any of the standard VNC viewers. 

ANY USER INTERFACE, ANYWHERE 

At ORL. we have used VNC to add mobility to workstation 
GUIs, where thte concept of at least some form of remote inter- 
action is not new. But the proiocors ^mpUcity could allow it to 
be used on a much wide* range of hardware. Consumer elec- 
tronics devices, such as CD playen. usually have a highly spe- 
cialized user Interface and typically employ custonUzed phys- 
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teal display devices. This has tradidonaily prevented such inter- 
faces from being mobile In the VNC sense of the word. 

But we think VNC s usefulness can be extended so that 
users could, for example, 

m bring up the controls for their video recorder on a 
mobile phone as they drive home from work. 

■ use a modem to dial a telephone answering machine and 
reprogram it through a graphical interface, 

■ display their car stereo or GPS receiver as part of the 
dashboard, regardless of the equipment brand installed. 

At present, such functions require the displaying device to 
have detailed knowledge of the remote system and to emu- 
late that systems user interface or some aiternaclve interface 
that it deems appropriate. For example, you would need a 
driver for your video recorder, which was designed for your 
mobile phones operating system. A much simpler approach 
would be to use the interface designed for and provided with 
the remote device, but to interact with it locally. 

For this we need a set of common "phonemes" with which 
we can construct a variety of GUIs. This is the role that the 
VNC protocol — or something very similar to it — can play. It 
is simple enough to implement cheaply In consumer elec- 
tronics hardware, yet It can be used to describe the building 
blocks of most modern user interfaces. With standards such 
as IEEE-1394 Firewire, USB. and IrOA. we have the physical 
interface to corviect a variety of devices; with VNC, we can 
add a standard for plug-and-play user interfaces. Imagine 
wallUng up to any workstation, connecting your PDA to the 
USB port, and having the PDA applications Instantly avail- 
able on the workstation screen, or plugging your PDA Into 
your car and having the engine management unit display ser- 
vicing Information on the PDAs screen. And imagine that 
this works for any worltstation, any PDA, any car. 

The engine management example Illustrates an Important 
point: A standardized GUI protocol allows devices that have 
no physical display of their own to provide graphical informa- 
tion when such a display becomes available to them. Your PDA 
could, perhaps, shrink to the size of a pen If it could access a 
display and keyboard through an IrDA link. And yet this 
"microPDA" could sUU display PowerPoint-style presentations 
when in the vicinity of an LCD projection panel or a large TV. 

This model is very similar to the Web, where services 
without an I/O capability of their own wait for a user to pro- 
vide one In the form of a Web browser. The success of this 
strategy has led to embedding HTTP daemons In printers, 
switches, routers, and other devices. But to be a Web serv- 
er, a device must at least have a TCP stack and an IP address. 
And to be a Web browser requires at least the ability to ren- 
der fonts and parse HTML. 

In contrast, VNC requires only a reliable transport medi- 
um and the simplest of display capabilities. And while a page of 




Figure 3. Remote access to a CD player control panel using 
the VNC system. 



HTML will generally require the transmission of fewer bytes 
than its VNC equivalent, the latter is infinitely more flexible. 

FUTURE WORK 

We are now building VNC software for a variety of desktop 
platforms, but it would not be difficult to make remote 
access practical for a wider range of devices. We can envis- 
age cheap hardware that might, for example, drive a 7- 
segment LCD and also emit a VNC equivalent over a USB 
or RS232 Unk. The VNC commands to draw and erase each 
segment could be stored as a sequence of bytes in a small 
amount of ROM and sent over a communications link when 
the segment Is lit or switched off. Hardware such as this, if 
made in quantity, could be very cheap and could allow for 
mobility of much more than Just a conventional "desktop." 
If built into television sets, VNC viewers could allow them 
to art as displays for a very wide range of devices — includ- 
ing, of course, the PC at the office. ■ 
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